The system moved through legitimate states until the combined sequence produced an illegitimate outcome.

That is the security challenge agentic AI introduces.

Traditional threat models often examine components and isolated attack events. Agentic AI systems require us to additionally model stateful attack paths across multiple trust boundaries.

A useful way to do that is to divide the architecture into five threat zones:

1. Input surfaces
2. Planning and reasoning
3. Tool execution
4. Memory and state
5. Inter-agent communication

The objective is not simply to secure each zone individually. It is to understand how malicious influence can move from one zone to the next.

What makes agentic AI different from a traditional LLM application?

A conventional LLM integration is often close to request-response:

Prompt → Model → Response

An agentic AI system introduces a loop.

The agent evaluates its current state, decides what to do next, acts through a tool or another agent, observes the result, and repeats the process until it reaches its goal or exhausts its budget.

Conceptually:

Think → Act → Observe → Repeat

During those iterations, an agent may:

• Call APIs
• Query databases
• Use MCP tools
• Read or write files
• Execute code
• Consult persistent memory
• Communicate with peer agents
• Modify cloud infrastructure
• Invoke additional agents

The important difference is that the model participates in deciding what happens next.

For security teams, that turns prompt injection from a response-manipulation problem into something potentially much more significant. A malicious instruction can influence an operational loop with access to real capabilities.

Why is traditional threat modeling not enough for agentic AI?

Traditional approaches such as component-oriented data-flow modeling remain valuable. But agentic systems introduce properties that are difficult to understand by examining components independently.

Three changes are particularly important.

Data and instructions share the same context

An LLM can receive system instructions, user prompts, retrieved documents, API responses, tool descriptions, and other content inside its working context.

The system may intend some of that information to be data only. The model, however, can still interpret text inside that data as instructions.

This is the foundation of indirect prompt-injection attacks.

Memory can cross sessions and users

Agents increasingly persist information beyond a single request.

That can include conversation state, cached results, long-term memory, or project-level files containing instructions about how future tasks should be performed.

If malicious state is persisted, an attack may survive the interaction in which it originated.

It may also affect another engineer or another session with different privileges.

Agents communicate with other agents

Multi-agent architectures introduce additional trust relationships.

If one agent accepts malicious input and then forwards the resulting context to another agent, that second agent may treat the message as trusted simply because it came from an internal peer.

A compromise can therefore cascade through the system.

These properties mean agentic AI security must focus not only on components but also on transitions, sequences, and accumulated state.

What are the five threat zones for agentic AI?

The five-zone model provides an architectural lens for following these attack paths.

Each zone represents a different type of trust—and every transition between zones should be treated as a trust boundary.

Threat Zone 1: Input Surfaces

The input-surface zone contains every channel through which external or potentially untrusted information reaches the agent.

The user prompt is only one such channel.

Other input surfaces include:

• Retrieved RAG documents
• Emails
• Enterprise knowledge bases
• Uploaded files
• External API responses
• Web content
• MCP tool descriptions
• Tool responses

A central threat-modeling assumption should therefore be:

Every input channel can potentially carry instructions, even when the application expects only data.

This matters particularly for retrieval-augmented generation. A retrieved document may be relevant to the user’s query and still contain malicious instructions.

The same principle applies to MCP. Tool descriptions themselves are input because the model reads them to decide when and how a tool should be called.

Threat Zone 2: Planning and Reasoning

The planning and reasoning zone is where the agent interprets its goal and decides what actions to perform.

This can include:

• Goal interpretation
• Task decomposition
• Tool selection
• Tool argument construction
• Selection of peer agents
• Evaluation of previous results

This zone becomes critical when malicious input changes the agent’s objective.

If an attacker can redirect the goal, the agent may begin using its legitimate capabilities to achieve the attacker’s objective instead of the user’s.

That is why agent goal hijacking is particularly dangerous.

Once the planning layer has been influenced, the attacker does not necessarily need to control every subsequent action. The agent can select tools and construct the necessary sequence itself.

Threat Zone 3: Tool Execution

The tool-execution zone is where an agent turns decisions into actions.

Tools may provide access to:

• Databases
• Internal APIs
• Cloud infrastructure
• MCP servers
• File systems
• Package registries
• Command-line operations
• Code execution

For a coding or DevOps agent, these capabilities can be highly privileged.

A compromised plan therefore becomes significantly more dangerous once it reaches the tool layer.

The key security principle is familiar but especially important here:

Permissions should be scoped to the current task, not to the complete set of tasks the agent might ever perform.

Where possible, agents should receive just-in-time capabilities rather than holding broad, long-lived privileges.

Threat Zone 4: Memory and State

The memory and state zone contains information that can influence future agent behavior.

Examples include:

• Conversation history
• Working memory
• Cached tool results
• Long-term storage
• Shared session state
• Repository-level agent instruction files

Memory creates a persistence dimension that conventional request-response applications often do not have.

Imagine that an agent writes a malicious or manipulated instruction into persistent project state. Another engineer later checks out the repository and runs an agent with more powerful tools or production permissions.

The original malicious input has now crossed both time and identity boundaries.

Threat models therefore need to ask:

Can attacker-controlled information become trusted memory?

And, equally importantly:

Is stored memory re-evaluated for provenance and trust before it influences a new plan?

Threat Zone 5: Inter-Agent Communication

The inter-agent communication zone covers messages and delegated tasks exchanged between collaborating agents.

This zone becomes critical in multi-agent systems because internal communication can create implicit trust.

Consider a customer-service architecture with:

• A customer-facing triage agent
• A knowledge agent
• A transaction agent
• A supervisor agent

The triage agent has the greatest exposure to attacker-controlled input.

The transaction agent may have the greatest privileges.

Connecting the two creates a potentially dangerous trust bridge.

If malicious customer input influences the triage agent and that context is forwarded downstream, the transaction agent may perform an unauthorized action while believing it is processing a legitimate internal request.

The important principle is:

A message does not become trustworthy merely because another agent sent it.

In a multi-agent system, the effective trust level of communication can be limited by the weakest participating agent.

Why should every cross-zone transition be a trust boundary?

Consider this attack path:

Input → Planning → Tool → Memory → Planning

A malicious document enters through an input surface.

The retriever places it into the model’s context.

The document influences planning.

The planner selects a legitimate tool.

The resulting state is persisted.

A future agent session reads that state and changes its behavior.

Every individual operation may appear valid when viewed locally.

The vulnerability only becomes visible when the complete sequence is modeled.

That is why cross-zone transitions must be explicit parts of the threat model rather than arrows that simply connect otherwise secure components.

Scenario 1: How can RAG poisoning compromise an enterprise AI assistant?

Consider an enterprise knowledge assistant using retrieval-augmented generation.

An employee asks a legitimate question.

The retriever queries a vector database and selects the most semantically relevant document chunks. Those chunks are inserted into the model context so the LLM can formulate its response.

Now introduce one poisoned document.

An attacker first needs to get malicious content into the corpus. Potential paths include:

• An external content source
• A compromised internal source
• A user-uploaded document without adequate provenance controls

Next, the attacker needs the retriever to rank the poisoned content highly enough to include it in the model context.

Once that happens, the attack crosses from Zone 1 into Zone 2.

If the LLM treats the retrieved text as instructions rather than untrusted content, the generated answer may contain attacker-controlled recommendations, malicious links, or misleading instructions.

The risk becomes greater when the compromised result enters Zone 4 and persists in a cache or conversation state.

The important lesson is that RAG security is not simply a vector-database problem.

The threat path spans:

Content ingestion → Retrieval → Planning → Response → Optional persistence

Scenario 2: How can attacks cascade through multiple AI agents?

A multi-agent customer-service system demonstrates a different cross-zone problem.

Assume a customer communicates with a triage agent. That agent can request information from a knowledge agent and eventually send an action to a transaction agent.

The transaction agent can modify customer accounts.

The attack begins with attacker-controlled input.

The malicious customer message influences the triage agent’s planning. The triage agent then passes enriched context through the internal agent network.

Eventually, the transaction agent receives a request that appears legitimate and executes an account modification.

A supervisor may observe that every expected agent-to-agent protocol was followed.

Locally, every step looks normal.

Globally, the sequence is malicious.

This highlights an important monitoring requirement:

Agent security must evaluate action sequences against the original user intent, not only inspect individual calls for anomalies.

Scenario 3: How can MCP tool descriptions become an attack vector?

MCP tool descriptions deserve particular attention because the agent actively reads them during planning.

A tool might legitimately advertise itself as:

• A dependency checker
• An infrastructure deployment tool
• A database utility
• A security scanner

But the description could also contain instructions that encourage the agent to access information beyond what the user requested.

For example, a malicious tool description could claim that a security or compliance check requires reading local environment files and sending their contents as part of a tool argument.

The attack combines classic social-engineering patterns:

Pretexting: the action appears to support a legitimate security process.

Justification: the model receives a reason why sensitive access is supposedly necessary.

Suppression: the description instructs the model not to disclose the additional action to the user.

MCP also creates a lifecycle risk.

A remote MCP server may expose a harmless tool description during approval and change it later.

The presentation describes this as a rug-pull attack.

One structural mitigation is to hash and pin the approved description. If that description changes, the tool should require renewed approval before execution.

How can attack trees improve agentic AI threat modeling?

The five threat zones show where to look.

Attack trees help model how an attacker gets from an entry point to an objective.

Start with a concrete attack goal.

Examples from the scenarios include:

• Deliver a poisoned answer to an employee
• Perform an unauthorized account modification
• Exfiltrate developer credentials through an MCP tool

Then decompose the attack into the conditions or steps required to reach that goal.

For RAG poisoning, an attack tree might contain:

1. Insert malicious content into the corpus.
2. Get the content ranked among the retrieved results.
3. Cause the model to interpret the content as instructions.
4. Optionally persist poisoned state.

Each node can then be associated with:

• A threat zone
• Attacker effort
• Required skill
• Detectability
• Complexity
• Security controls

This is particularly useful for AI systems because many AI-layer defenses are probabilistic.

A prompt-injection classifier or LLM guardrail does not create the same deterministic boundary as a network rule.

Attack trees make it possible to model control failure explicitly and ask:

If this classifier is bypassed, what other control still stops the attack path?

Which security controls matter most across the five threat zones?

Agentic AI security requires layered defenses. Probabilistic model-level protections should be backed by structural controls that do not depend on the model making the right decision.

Preserve provenance and trust levels

Every input should retain information about its origin and trust level.

An employee-authored internal procedure, a public webpage, an uploaded document, and an MCP description should not become equivalent simply because all four appear inside the model context.

Separate data from instructions as far as the architecture allows

LLMs do not provide a hard boundary between data and instructions inside their context.

Applications should therefore preserve that distinction externally wherever possible and avoid giving retrieved content unnecessary authority over agent behavior.

Enforce least privilege per task

Tool access should be restricted to the immediate task.

A DevOps agent should not automatically receive every capability available to the engineer on whose behalf it acts.

Just-in-time permission models can reduce the blast radius of a compromised plan.

Prefer structural controls to probabilistic controls

Useful structural protections include:

• Network allowlists
• Restricted outbound communication
• Sandboxed tools
• Container isolation
• Process isolation
• Session isolation

These controls provide boundaries outside the model’s reasoning process.

Protect trust boundaries between agents

High-exposure agents should not freely instruct high-privilege agents.

Agent-to-agent communication should have authorization, validation, and capability boundaries comparable to other security-sensitive service interactions.

Use human approval where it matters

Human approval can reduce risk for sensitive actions.

But requiring constant confirmation creates approval fatigue and can turn the human into a rubber stamp.

Human-in-the-loop controls should therefore focus on high-impact transitions and adapt to risk.

Monitor the complete action sequence

Monitoring should correlate what the system does with what the user originally asked it to accomplish.

A database query might be valid.

A network request might be valid.

A financial operation might be valid.

A sequence containing all three during an unrelated support request may not be.

What is the lethal trifecta in agentic AI security?

A useful heuristic discussed in the presentation is the lethal trifecta.

An agent becomes particularly dangerous when one session simultaneously has:

1. Access to private data
2. Exposure to untrusted content
3. The ability to communicate externally

Two of those properties may be necessary for legitimate functionality.

Combining all three creates a straightforward attack path:

Untrusted content influences the agent → the agent accesses sensitive data → the agent sends that data outside the trust boundary.

A strong architecture should therefore ask whether any single agent session actually needs all three capabilities at once.

If not, separating them can eliminate an entire class of attack paths.

What should teams review at each threat-zone boundary?

A practical agentic AI security review can be organized around a few cross-zone questions.

Input → Planning

Does every input retain its provenance and trust level?

Can retrieved documents, web pages, email content, or tool descriptions reach a context where the model may treat them as instructions?

Planning → Tools

Are tools and credentials restricted to the current task?

Are sensitive actions protected by stronger authorization or an appropriate human gate?

Tools → Memory

Can unvalidated tool output be persisted directly?

Could poisoned state survive into later sessions?

Memory → Planning

Is stored context checked for origin and trust before reuse?

Can stale or compromised memory silently redirect a new task?

Agent → Agent

Can a highly exposed agent directly influence a highly privileged agent?

Does the receiving agent verify the authorization and intent behind delegated actions?

Across all zones

Which outbound channels could be used for exfiltration?

Is the complete action chain continuously compared with the user’s original intent?

A practical workflow for threat modeling agentic AI systems

The five-zone model can be turned into a repeatable security process.

1. Map the architecture to the five threat zones

Identify:

• Input surfaces
• Planning components
• Tool capabilities
• Persistent state
• Agent-to-agent communication

Do not limit the map to obvious user-facing interfaces.

2. Identify cross-zone entry points

Trace how information moves between zones.

Pay particular attention to retrieved documents, external content, MCP descriptions, tool responses, shared memory, and inter-agent messages.

3. Define realistic attacker goals

Ask the familiar threat-modeling question:

What is the worst outcome if this agent goes haywire?

For a knowledge assistant, that may be delivering false instructions.

For a customer-service system, it may be an unauthorized account modification.

For a DevOps agent, it may be accessing or exfiltrating production credentials.

4. Build attack trees for critical flows

Decompose each attacker goal into the steps necessary to achieve it.

Map those steps back to the five threat zones.

5. Map risks to agentic security controls

Use frameworks such as the OWASP Agentic Security Initiative to connect concrete attack paths with relevant mitigation categories.

The five zones provide the architectural map; the risk framework provides a catalog of failure modes and potential controls.

6. Challenge the controls

Do not assume a guardrail is perfect.

Model what happens if classifiers, filters, or LLM-based protections fail.

Look for deterministic compensating controls and identify chokepoints where one additional protection could break several possible attack paths.

7. Validate the architecture against agent-specific assumptions

Finally, account for properties that distinguish agents from deterministic applications:

• Non-determinism
• Autonomous decision-making
• Delegated identity
• Varying trust between agents

These characteristics should influence both the threat model and the monitoring strategy.

The key shift: Threat model the campaign, not only the component

Agentic AI does not make traditional security engineering obsolete.

Authentication still matters.

Authorization still matters.

Least privilege, network restrictions, sandboxing, isolation, auditing, and secure software supply chains still matter.

But they are no longer sufficient when considered only component by component.

Agentic systems can combine individually legitimate operations into an unsafe sequence. Untrusted input can alter planning. Planning can invoke privileged tools. Tool results can become persistent memory. Memory can influence future sessions. One compromised agent can redirect another.

That is why the most useful question when threat modeling agentic AI is not simply:

“Is every component secure?”

It is:

“Can this system move through legitimate states and still arrive at an outcome the user never intended?”

If the answer is yes, the architecture still has an attack path worth modeling.

The five threat zones—input surfaces, planning and reasoning, tool execution, memory and state, and inter-agent communication—provide a practical map for finding those paths before an attacker does.